home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / EDITOR / KDP32_1.ARJ / KANJI.DOC < prev    next >
Text File  |  1992-05-22  |  16KB  |  314 lines
  1.                          CHARACTER CODING OF JAPANESE
  2.  
  3. ******************************************************************************
  4. *   This archive contains the kanji font file KDP16SJ.FNT, which is needed   * 
  5. *   by  the KDPLUS kanji preprocessor system. For those who would like  to   *
  6. *   know  how  the font file is organized, the following notes  have  been   *
  7. *   provided which explain Japanese character coding.                        *
  8. ******************************************************************************
  9.  
  10. 1) Starting point: the ku-ten table
  11. All characters used in Japanese writing can be arranged in a table which is 
  12. called the "ku-ten" table. The table, which is universally used, is 94 columns 
  13. wide and 94 rows high, but rows 85 and up are empty (not used) at present.
  14.  
  15. Numbering of rows and columns starts at 1 (not zero). Any character can be 
  16. identified by specifying its row number (called its "ku" value) and its column 
  17. number (called its "ten" value). 
  18.  
  19. The symbols in rows 1-47 are called "level 1 JIS (Japan Industrial Standard) 
  20. characters"; they are the most commonly used characters. Rows 48 and up are 
  21. called "level 2 JIS". The level 1 kanji (from row 16) are arranged according 
  22. to pronunciation (on-yomi normally) and stroke count.
  23.  
  24. A print-out of the "ku-ten" table can be found in the instruction manual of
  25. every Japanese "wapro" (word-processor) and every Japanese printer. In many
  26. "wapros" the ku-ten values of characters may be entered by hand. "Office
  27. Automation Dictionaries", available in Japan, enable you to look up the "ku-
  28. ten value" of any character.
  29.  
  30. The "ku-ten" table is not completely standardized in Japan. The standardiza-
  31. tion applies only to rows 1-8 (kana, alphanumerics) and rows 16 and up
  32. (kanji); they are defined in JIS standard X-0208. Rows 9-15 are left blank in
  33. the standard and can, apparently, be filled in by manufacturers according to
  34. their own ideas. The blank areas in rows 1-8 are considered "reserved".
  35.  
  36. The complete ku-ten table is contained in six files which go with this archive
  37. (see section 5).
  38.  
  39. 2) Kanji fonts
  40. A kanji font is a set of binary data (a ROM chip, or a disk file) describing
  41. the actual appearance of the symbols. The file KDP16SJ.FNT is an "almost"
  42. standard 16 x 16 pixel kanji font (see section 7 for a summary of the changes
  43. which were made). It contains bitmap images of characters, each bitmap 16
  44. pixels wide and 16 pixels high; each bitmap therefore occupies 32 bytes.
  45.  
  46. The character bitmaps are arranged sequentially in the font file according to
  47. the character's position in the ku-ten table. The offset (in bytes) of the
  48. bitmap corresponding to character [ku,ten] is 32*((ku-1)*94+ten-1). The font
  49. file contains bit-maps for the first 83 rows of the ku-ten table (row 85 and
  50. up are empty anyhow, and row 84 contains only 5 rarely-used characters, so
  51. this is no great loss). The total number of character images in the font is
  52. thus 94*83=7802.
  53.  
  54. The ku-ten table contains many gaps (incompletely filled rows). For instance,
  55. in row 8 only the first 32 places are filled (with line draw symbols), the
  56. rest is blank. Row 14 originally contained only 3 symbols (but now we have
  57. added some IBM control characters to that row). The blank areas are left blank
  58. in the font file; in other words, they are not skipped, but are represented by
  59. bit-map tables which consist of zeroes. This is, of course, a waste of space,
  60. but it makes for flexibility (you can put your own symbols there if you wish)
  61. and easy decoding.
  62.  
  63. In the file KDP16SJ.FNT, the bitmap images in rows 9, 10, and 11 use only the
  64. left-hand half of the 16 x 16 pixel box. They can be displayed with a
  65. horizontal spacing of 8 pixels. 8-pixel, or half-character, symbols are called
  66. hankaku; characters which use the full 16 x 16 box are called zenkaku. In a 24
  67. x 24 pixel font, zenkaku characters are be 24 pixels wide, hankaku characters 
  68. are 12 pixels wide (in the font KDP24SJ.FNT, used by KPLJ24, the hankaku 
  69. characters are in fact 13 pixels wide; KPLJ24 inserts 2 empty pixels between 
  70. zenkaku characters to keep the zenkaku spacing twice the size of the hankaku 
  71. spacing). 
  72.  
  73.  
  74. 3) JIS coding
  75. The number of columns in the ku-ten table, 94, is not arbitrary; it is derived
  76. from the number of 7-bit ASCII characters. With 7 bits, 128 different
  77. characters can be represented; leaving out the characters 0 and 127, and also
  78. the characters 1-32 (control characters and space), we are left with 94
  79. printable characters, having the numerical values 33-126.
  80.  
  81. Any character in the ku-ten table can now be represented by 2 bytes:
  82.  
  83.         first byte : "ku"  value + 32
  84.         second byte: "ten" value + 32
  85.  
  86. The first character in the ku-ten table, [ku=1, ten=1] is thus represented by
  87. the two bytes [33,33]. The first kanji character in the table (the character
  88. with pronunciation "A", meaning Asia), with ku=16 and ten=1, would be
  89. represented by the bytes [48,33], or, in ASCII, "0!".
  90.  
  91. Thus we have a system of transmitting Japanese characters on channels which
  92. use 7-bit characters (especially mainframe systems). This is called the JIS
  93. code.
  94.  
  95. The problem which now arises is this: a terminal capable of receiving kanji
  96. data according to the system described above would interpret each character as
  97. one half of a kanji. It could not receive normal ASCII text without changing
  98. it into some garbled mess of kanji and kana. It would, of course, be desirable
  99. if the same terminal could interpret ASCII characters according to their
  100. normal meaning ALSO. The solution which was adopted for this may be inelegant, 
  101. but is unavoidable within the limitations of the 7-bit format. It consists of 
  102. switching between two modes: "ASCII mode" and "kanji mode". The mode is 
  103. switched by means of an escape sequence. JIS code systems need two escape 
  104. sequences:
  105.  
  106.         kanji in  (KI) sequence: changes from ASCII mode to kanji mode
  107.         kanji out (KO) sequence: changes from kanji mode to ASCII mode
  108.  
  109. Of course, the disadvantage of this method is that the KI and KO strings may
  110. become garbled in transmission, leaving the system in the wrong mode. But I 
  111. suppose a better solution wasn't possible in systems using only seven bits.
  112.  
  113. KI and KO strings differ, according to the "dialect" of the JIS code which is
  114. in use. Three major dialects are "old JIS", "new JIS", and "NEC", which have 
  115. respectively:
  116.                         KI           KO
  117.                         =======      =======
  118.            old JIS      ESC $ @      ESC ( H
  119.            new JIS      ESC $ B      ESC ( J   
  120.            NEC          ESC K        ESC H (pica), ESC E (elite)
  121.  
  122. "Old JIS" is, for instance, used by JICST and the Nikkei Telecom News data-
  123. base service. "New JIS" is used by the kanji editor program MOKE (by Mark 
  124. Edwards), and in the Japanese section of the GENIE network. NEC printers use 
  125. the NEC code.
  126.  
  127. Some JIS systems can also handle hankaku katakana characters. These characters
  128. are encoded by one byte, with value 21 - 5f hex. To indicate that such codes
  129. must be interpreted as hankaku katakana rather than normal ASCII, hankaku
  130. katakana strings must be preceded and followed by special codes:
  131.  
  132.         the character SO (Ehex) switches from ASCII to hankaku katakana;
  133.         the character SI (Fhex) switches from hankaku katakana to ASCII.
  134.         
  135. This system is used to communicate with the 7-bit, "old JIS" data-bank JICST. 
  136. You initiate a search by typing a keyword in ASCII or hankaku katakana
  137. (JICST does not accept zenkaku characters for input). The response from the
  138. system is in ASCII and "old JIS" zenkaku characters. 
  139.  
  140. The default mode for JIS systems is ASCII mode.
  141.  
  142.  
  143. 4) EUC coding
  144.  
  145. EUC (Extended Unix Code) is a variant of JIS which is used on eight-bit UNIX
  146. systems such as can be found in university environments. The coding system is
  147. exactly the same as JIS, but the switch between ASCII mode and Kanji mode is
  148. not indicated by escape strings. Instead, characters in kanji sequences have
  149. the high bit set, while ASCII characters have the high bit cleared (zero).
  150.  
  151.  
  152. 5) SJIS coding
  153.  
  154. In bulletin board systems (which are always 8-bit), and frequently also for
  155. internal character representation in Japanese personal computers, the so-called
  156. SJIS code is used. SJIS means shift-JIS, probably to indicate that "shifted"
  157. (high bit set) characters are used. They are used, however, in a way which is
  158. very different from that of the EUC system.
  159.  
  160. There are three kinds of SJIS codes: controls, one-byte characters, and two-
  161. byte characters.
  162.  
  163. Controls are represented by one byte, having the values 0-1f hex, or 0-31
  164. decimal. Controls include codes for new line, carriage return, form feed, back
  165. space, etc.
  166.  
  167. One byte characters are represented by one byte having a value ranging from 20
  168. to 7E hex (32 to 126 decimal) or from A0 to DF hex (160 to 223 decimal). For
  169. values in the rage 20 to 7E hex, the meaning of the characters is the same as
  170. in standard ASCII. The range A1 to DF hex is used for hankaku katakana; these
  171. values are the same as the JIS hankaku katakana, but with the high bit set. On
  172. the IBM PC, this range is occupied by the "box draw" characters. The value
  173. A0 hex represents a space (same as 20 hex).
  174.  
  175. A peculiarity is that on some systems (for instance the KDPLUS system) the
  176. one-byte characters can also be coded with two bytes; this is the case when
  177. the characters have been put somewhere in the non-standardized part of the ku-
  178. ten table, so that they have a normal two-byte address. On some systems (an
  179. example is the Ichitaro word-processing system on an AX) ASCII and hankaku
  180. katakana are kept out of the ku-ten table altogether, so these characters can
  181. only be selected with one-byte codes.
  182.  
  183. Two-byte characters are represented by a "high" byte followed by a "low" byte.
  184. In order not to be mistaken for a control or a one-byte character, the "high"
  185. byte must use values which are not used by those characters, in the ranges 81-
  186. 9F hex and E0-EA hex. The "low" byte uses values in the range 40-FC hex, but
  187. the value 7F hex is skipped (not used). This may be a relic from the paper
  188. tape era. On paper tape systems, "all holes punched" was never used for a
  189. character, so that it was possible to erase characters on the tape by
  190. overpunching them.
  191.  
  192. There are 188 possible values for the "low" byte and 42 for the "high" byte.
  193. Every possible value of the "high" byte can now encode 2 rows (2 x 94
  194. characters) of the "ku-ten" table. In total therefore, 84 rows could be
  195. encoded, but only one row is encoded for the characters with "high byte" equal
  196. to EA hex.
  197.  
  198. The algorithm for converting "ku-ten" values to "high-low" values is:
  199.  
  200.  high=0x80+(ku+1)/2 ;         /* 2 ku values share the same high byte. */
  201.   if (high>0x9F) high+=0x40;  /* if outside 81-9F range, lift to E0-EA range*/
  202.   if (ku&1)  {                /* ku is odd*/
  203.                low= 0x3F+ten;
  204.                if (low>=0x7F) low++;
  205.              }
  206.   else         low= 0x9E+ten;   /* ku is even */
  207.  
  208. The decoding algorithm is equally straightforward: assume that we have already
  209. determined that a two-byte character has been sent, and we have the "high" and
  210. "low" bytes available. We calculate the "ku" and "ten" values as follows:
  211.  
  212.      if (high>=0xE0) high-=0x40;
  213.      high-=0x80;
  214.      ku=2*high - 1;     /* always produces an odd value */
  215.  
  216.      if (low > 0x9E)  { /* ku is even: increase the value */
  217.                         ku++;
  218.                         ten=low-0x9E;
  219.                       }
  220.      else             { /*ku is odd*/
  221.                         if (low>0x7F) low--;
  222.                         ten=low-0x3F;
  223.                       }
  224.  
  225. The treatment of the one-byte characters depends on where the hankaku 
  226. characters are stored in the font, because this is hardly standardized. In the 
  227. font KDP16JS.FNT, the hankaku ASCII characters are stored in row 9, and
  228. hankaku katakana in row 10. So we calculate "ku" and "ten" as follows:
  229.  
  230.  if (ch<0x20)                      { /* control character */
  231.                                      /*....put appropriate code here....*/
  232.                                    }
  233. else if ((ch==0x20)||(ch==0xA0))   { /* hankaku space */
  234.                                       ku=11;
  235.                                       ten=1;
  236.                                     }
  237.                               /*  The separate treatment of the hankaku  space 
  238.                                   is  necessary, because, inconveniently,  the 
  239.                                   hankaku ASCII row in the font file does  not 
  240.                                   start with a space, but with the exclamation 
  241.                                   mark (ASCII 0x21). We get the space from row 
  242.                                   11, which does start with a space. */
  243.  
  244. else if ((ch>0x20)&&(ch <= 0x7E))   {/* ASCII */
  245.                                      ku=9;
  246.                                      ten=ch-0x20;
  247.                                     }
  248. else if ((ch>0xA0)&&(ch <= 0xDF))   {/* hankaku katakana */
  249.                                      ku=10;
  250.                                      ten=ch-0xA0;
  251.                                     }
  252.  
  253. else                                { /* not a one-byte character, but
  254.                                          first half of two-byte character. */
  255.                                       /*....put appropriate code here.... */
  256.                                     }
  257.  
  258.  
  259. Of course many tricks can be applied to make the code more compact and faster. 
  260. The separate treatment of the hankaku space can also be avoided with a small 
  261. trick. The above explanation shows the principle, however.
  262.  
  263. It is quite easy to make your program recognize KI and KO strings, and switch
  264. automatically between SJIS and JIS coding. It is not so easy to distinguish
  265. automatically  between  SJIS  and EUC (at least not on  the  basis  of  single
  266. characters).
  267.  
  268. 6) "Ku-ten" table files
  269.  
  270. You can obtain a print-out of the ku-ten tables for Level 1 and Level 2 JIS
  271. by printing the files:
  272.  
  273. level1.1
  274. level1.2
  275. level1.3
  276.  
  277. (for Level 1 JIS)
  278.  
  279. level2.1
  280. level2.2
  281. level2.3
  282.  
  283. (for Level 2 JIS)
  284.  
  285. Because the ku-ten tables are too wide to be printed on one sheet, they have
  286. been split into three parts, covering the columns 1-32, 33-64, and 65-94
  287. respectively. You can print all three of them on a Japanese printer or word
  288. processing system, or on a "Western" printer using the print utilities of the
  289. KDPLUS system. Glue the tables together to get complete ku-ten tables.
  290. The tables are SJIS coded. To convert to JIS, use the KDPLUS SJIS2JIS utility.
  291.  
  292. 7) Changes made in KDP16SJ.FNT
  293. A few changes have been made in KDP16SJ.FNT to adapt it for use with KDPLUS
  294. and the KDPLUS editor, JWRITE. The most important of those changes is that the
  295. IBM control code symbols (corresponding to ASCII values below 32) have been
  296. added to row 14 of the font, from position 11, and the IBM characters with
  297. values EB-FE are in that same row from position 75. Furthermore, the character
  298. ASCII 92 (5C hex), corresponding to ku=9, ten=60, is now displayed
  299. as a backslash, to make it conform to normal IBM PC usage (in the original
  300. KDP16SJ.FNT, as on most Japanese computer systems, this character is a "yen"
  301. sign). Also, some cosmetic changes have been made in the "tilde", apostrophe,
  302. reverse apostrophe, and quotation mark symbols, to make them useable as
  303. accents. The "equals" sign (=) has also been slightly modified. In combination
  304. with the capital Y, it makes a nice "yen" sign (through the accent facility of
  305. JWRITE), should you need it.
  306.  
  307. If you don't like these changes, you can undo them using the font editor
  308. KFEDIT that comes with KDPLUS.
  309.  
  310.  
  311. Tokyo, 10 July 1991 (revised 14 January 1992, 16 February 1992, 20 May 1992)
  312. Jan W. Stumpel
  313.  
  314.